RPC Under Fire

I n 1976, James E. White of the Stanford Research Institute published details in RFC 707 about what would come to be called the remote procedure call (RPC).1 He described his “procedure call model” as a way of making the networked environment seem completely familiar to application developers, rather than exposing the network directly to them and thus presenting them with a development model so different that they would be scared away from writing distributed programs. Bruce Jay Nelson and Andrew D. Birrell of the Xerox Palo Alto Research Center published their seminal paper on implementing RPC in 1984.2 Their work provided the cornerstone for the many RPC-based distributed systems that would follow, including Apollo’s Network Computing System (NCS), Sun RPC, the Open Software Foundation (OSF) Distributed Computing Environment (DCE), and various objectoriented offspring such as Corba, Microsoft COM, and Java Remote Method Invocation (RMI). Although many successful distributed systems have been built using RPC, we’ve known for a while that it’s imperfect, even fundamentally flawed, because it ignores the all-too-real possibility of partial failures by attempting to make the network appear to be just another part of the local environment. A partial failure occurs in a distributed system when a remote application or the network itself fails, thereby introducing the need for applications to handle error conditions that simply can’t arise with local procedure calls. Lately, however, RPC seems to be taking even more heat than usual, mainly because of continuing advances in Web services and XML-based messaging.